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Mapping between X.400 and RFC-822 Message Bodies 
Status of this Memo 


This RFC specifies an IAB standards track protocol for the Internet 
community, and requests discussion and suggestions for improvements. 
Please refer to the current edition of the "IAB Official Protocol 
Standards" for the standardization state and status of this protocol. 
Distribution of this memo is unlimited. 
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1. Introduction 
The Internet community is a large collection of networks under 
autonomous administration, but sharing a core set of protocols. 
These are known as the Internet suite of protocols (or simply 
"TCP/IP"). 


Use of electronic-mail in the Internet is defined primarily by one 
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document, STD-11, RFC-822 [1], which defines the standard format for 
the exchange of messages. RFC-822 has proven immensely popular; in 
fact, the 822-connected Internet, is larger than the scope of the 
IP-connected Internet. 


The framework provided by RFC-822 allows for memo-based textual 
messages. Each message consists of two parts: the headers and the 
body. The headers are analogous to the structured fields found in an 
inter-office memo, whilst the body is free-form. Both parts are 
encoded using ASCII. 


Recently, the Internet Engineering Task Force (IETF) has developed an 
document called, 


Multipurpose Internet Mail Extensions 


or MIME RFC-1341. The title is actually misleading. MIME defines 
structure for Internet message bodies. It is not an extension to 
RFC-822. 


Independently of this, the International standards community 
developed a different framework in 1984 (some say that’s the 
problem). This framework is known as the OSI Message Handling System 
(MHS) or sometimes X.400. 


Since the introduction of X.400(84), there has been work ongoing for 
defining mappings between MHS and RFC-822. The most recent work in 
this area is RFC-1327 [3], which focuses primarily on translation of 
envelope and headers. This document is complimentary to RFC-1327 as 
it focuses on translation of the message body. The mappings defined 
are largely symmetrical with respect to MIME and MHS structuring 
semantics, although the MIME semantics are somewhat richer. In order 
to provide for reversible transformations, MHS heading extensions are 
used to carry the additional MIME semantics. 


Please send comments to the MIME-MHS mailing list: 
<mime-mhs@surfnet.nl>. 


2. Approach 


The mappings have been specifically designed to provide optimal 
behavior for three different scenarios: 


(1) Allow a MIME user and an MHS user to exchange an arbitrary binary 
content; 


(2) Allow MIME content-types to "tunnel" through an MHS relay that 
is, two MIME users can exchange content-types without loss 
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through an MHS relay); and, 


(3) Allow MHS body parts to "tunnel" through a MIME relay that is, 
two MHS users can exchange body parts without loss through a MIME 
relay). 


Other, related, scenarios can also be easily accommodated. 


To facilitate the mapping process, the Internet Assigned Numbers 
Authority (IANA) maintains a table termed the "IANA MHS/MIME 
Equivalence Table". Once an enterprise has registered an OID to 
describe an MHS body part, it should complete a corresponding 
registry with the IANA for a MIME content-type/subtype. In practice, 
the corresponding content-type will be "application", with an 
appropriate choice of sub-type and possible parameters. If a new 
MIME content-type/subtype is registered with the IANA without a 
corresponding entry in the Equivalence Table, the IANA will assign it 
an OID, from the arc defined in this memo. See [4], section 5 for 
details. 


The companion document, "Equivalences between 1988 X.400 and RFC-822 
Message Bodies"[4], defines the initial configuration of this table. 
The mappings described in both this document and the companion 
document use the notational conventions of RFC-1327. 


3. Mapping between X.400 and RFC-822 Message Bodies 
MHS messages are comprised of an IPMS.heading and an IPMS.body. The 


IPMS.Body is a sequence of IPMS.BodyParts. An IPMS.BodyPart may be a 
nested message (IPMS.MessageBodyPart). 


A MIME message consists of headers and a content. For the purpose of 
discussion, the content may be structured (multipart or message), or 
atomic (otherwise). An element of a structured content may be a 
message or a content. Both message and structured content have 


subtypes which do not have direct analogies in MHS. 


The mapping between X.400 and RFC-822 message bodies which this 
document defines is symmetrical for the following cases: 


(1) any atomic body part 
(2) multipart: digest and mixed subtypes 
(3) message/rfc822 


RFC-1327 specifies the mappings for headers. Section 4 describes how 
those mappings are modified by this document. When mapping between 
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an MHS body and a MIME content, the following algorithm is used: 
3.1. Mapping from X.400 to RFC-822 


This section replaces the text in RFC-1327 starting at the bottom of 
page 84, 


The IPMS.Body is mapped into the RFC-822 message body. Each 
IPMS.BodyPart is converted to ASCII as follows: 


and continuing up to and including page 86 of Section 5.3.4 of RFC- 
1327. 


If the IPMS.Body 


Body ::= 
SEQUENCE OF 
BodyPart 


consists of a single body part, then the RFC-822 message body is 
constructed as the MIME content corresponding to that body part. 


If the body part is an IPMS.MessageBodyPart (forwarded IPM), the 
mapping is applied recursively. Otherwise, to map a specific MHS 
body part to a MIME content-type, the IANA MHS/MIME Equivalence table 
is consulted. If the MHS body part is not identified in this table, 
then the body-part is mapped onto an "application/x400-bp" content, 
as specified in [4]. 


If the IPMS.Body consists of more than one body part, then the RFC- 
822 message body is constructed as a 


multipart/mixed 


content-type, unless all of the body parts are messages, in which 
case it is mapped to a 


multipart/digest 


content-type. Each component of the multipart content-type 
corresponds to a IPMS.BodyPart, preserving the ordering of the body 
parts in the IPMS.Body. 


There is one case which gets special treatement. If the IPMS.Body 
consists solely of a single IA5Text body part, then the RFC822 
message body is NOT marked as a MIME content. This prevents RFC822 
mailers from invoking MIME function unnecessarily. 
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3.2. Mapping from RFC-822 to X.400 


First, replace the first paragraph of Section 5.1.3 on page 72 of 
RFC-1327 to read as: 


The IPM (IPMS Service Request) is generated according to the 
rules of this section. The IPMS.body usually consists of one 
IPMS.BodyPart of type 

IPMS .IA5TextBodyPart 


with 
IPMS.IA5TextBodyPart.parameters.repertoire 


set to the default (ia5), which contains the body of the RFC-822 
message. However, if the 822.MIME-Version header field is 
present, a special algorithm is used to generate the IPMS.body. 
Second, replace the "Comments:" paragraph on page 74 to reads as: 


Comments: 


If an 822.MIME-Version header field is not present, 
generate an IPMS.Bodypart of type 


IPMS .IA5TextBodyPart 
with 

IPMS.IA5TextBodyPart.parameters.repertoire 
set to the default (ia5), containing the value of 


the fields, preceded by the string "Comments: ". 
This body part shall preceed the other one. 


Third, add the remainder of this section to the end of Section 5.1.3 
of RFC-1327. 


If the 822.MIME-Version header field is present, the following 
mapping rules are used to generate the IPMS.body. 


If the MIME content-type is one of: 
(1) any atomic body part 


(2) multipart: digest and mixed subtypes 
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(3) message/rfc822 


then the symmetric mapping applies as described in Section 6.1. Note 
that the multipart content-types should be marked with the 
IPMS.HeadingExtension described below. 


Otherwise, three cases remain, which are discussed in turn. 
3.2.1. Asymmetric Mappings 
3.2.1.1. Message/External-Body 

This is mapped into a mime-body-part, as specified in [4]. 
3.2.1.2. Message/Partial 


This is mapped onto a message, and the following heading extension is 
used. The extension is derived from the message/partial parameters: 


partial-message HEADING-EXTENSION 
VALUE PartialMessage 
:= id-hex-partial-message 


PartialMessage 
SEQUENCE { 
number INTEGER, 
total INTEGER, 
id TA5String 


} 


If this heading is present when mapping from MHS to MIME, then a 
message/partial should be generated. 


3.2.1.3. Nested Multipart Content-types 


In MIME, a multipart content refers to a set of content-types, not a 
message with a set of content-types. However, a nested multipart 
content will always be mapped to an IPMS.MessageBodyPart, with an 
IPMS.BodyPart for each contained content-type. 


The only mandatory field in the heading is the IPMS.this-IPM, which 
must always be generated (by the gateway). A IPMS.subject field 
should also be generated where there is no "real" heading. This will 
present useful information to the non-MIME capable X.400(88) and to 
all X.400(84) UAs. 


Alvestrand, Kille, Miles, Rose & Thompson [Page 6] 


RFC 1495 MHS/RFC-822 Message Body Mapping August 1993 


The IPM.subject fields for the various types are: 


mixed: "Multipart Message" 

alternative: "Alternate Body Parts containing the same information" 
digest: "Message Digest" 

parallel: "Body Parts to be interpreted in parallel" 


3.2.2. Multipart IPMS Heading Extension 


The following IPMS.HeadingExtension should be generated for all 
multipart content-types, with the enumerated value set according to 
the subtype: 


multipart-message HEADING-EXTENSION 
VALUE MultipartType 
::= id-hex-multipart-—message 


MultipartType ::= 
ENUMERATED { 
mixed(1), 
alternative (2), 
digest (3), 
parallel (4) 
} 


If this heading is present when mapping from MHS to MIME, then the 
appropriate multipart content-type should be generated. 


4. Mapping between X.400 and RFC-822 Message Headers 


Replace the first paragraph of Section 3.3.4 on page 26 of RFC-1327 
to read as: 
In cases where T.61 strings are used only for conveying human- 
interpreted information, the aim of this mapping is to render 
the characters appropriately in the remote character set, rather 
than to maximize reversibility. For these cases, the following 
steps are followed to find an appropriate encoding: 


1) If all the characters in the string are contained within the 
ASCII repertoire, the string is simply copied. 


2) If all the characters in the string are from an IANA- 
registered character set, then the appropriate encoded-word(s) 
according to [5] are generated instead. 


3) If the characters in the string are from a character set 


which is not registered with the IANA, then the mappings to IA5 
defined in CCITT Recommendation X.408 (1988) shall be used 
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[CCITT/ISO88a]. These will then be encoded in ASCII. 


This approach will only be used for human-readable information 
(Subject and FreeForm Name). 


When mapping from an RFC-822 header, when an encoded-word (as 
defined in [5]) is encountered: 


1) If all the characters contained therein are mappable to T.61, 
the string content shall be converted into T.61. 


2) Otherwise, the encoded-word shall be copied directly into the 
T.61 string. 


Modify procedure "2a" on page 56 of RFC-1327 to read as: 
If the IPMS.ORDescriptor.free-form-name is present, convert it 
to ASCII or T.61 (Section 3.3.4), and use this as the 822.phrase 
component of the 822.mailbox construct. 


Modify the final paragraph of procedure "2" on page 55 of RFC-1327 to 


read as: 
The string is then encoded into T.61 or ASCII using a human- 
oriented mapping (as described in Section 3.3.4). If the string 


is not null, it is assigned to IPMS.ORDescriptor.free-form.name. 


Modify the second paragraph of procedure "3" on page 55 of RFC-1327 
to read as: 
If the 822.group construct is present, any included 822.mailbox 
is encoded as above to generate a separate IPMS.ORDescriptor. 
The 822.group is mapped to T.61 or ASCII (as described in 
Section 3.3.4), and an IPMS.ORDescriptor with only an free- 
form-name component is built from it. 


Modify procedure "822.Subject" on page 62 of RFC-1327 to read as: 


Mapped to IMPS.Heading.subject. The field-body uses the human- 
oriented mapping referenceed in Section 3.3.4. 


Modify procedure "IPMS.Heading.subject" on page 71 of RFC-1327 to 


read as: 
Mapped to "Subject:". The contents are converted to ASCII or 
T.61 (Section 3.3.4). Any CRLF are not mapped, but are used as 


points at which the subject field must be folded. 
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5. OID Assignments 


MIME-MHS DEFINITIONS ::= BEGIN 


mail OBJECT IDENTIFIER ::= { internet 7 } 


mime-mhs OBJECT IDENTIFIER ::= { mail 1 } 


mime-mhs-headings OBJECT IDENTIFIER ::= { mime-mhs 1 } 


id-hex-partial-message OBJECT IDENTIFIER ::= 
{ mime-mhs-headings 1 } 


id-hex-multipart-message OBJECT IDENTIFIER ::= 
{ mime-mhs-headings 2 } 


mime-mhs-—bodies OBJECT IDENTIFIER ::= { mime-mhs 2 } 
END 

6. Security Considerations 
There are no explicit security provisions in this document. However, 
a warning is in order. This document maps two mechanisms between 
RFC822 and X.400 that could cause problems. The first is the 
transfer of binary files. The inherent risks are well known and 
won’t be reiterated here. The second is the propagation of strong 


content typing. The typing can be used to automatically "launch" or 
initiate applications against those contents. Any such launching 
leaves the invoker vulnerable to application-specific viruses; for 
example, a spreadsheet macro or Postscript command that deletes 
files. See [2], Section 7.4.2 for a Postscript-—specific discussion 
of this issue. 
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